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(57) ABSTRACT 

A method for managing memory in an object oriented 
program that is capable of using a plurality of fixed pool 
classes and a plurality of objects belonging to those fixed 
pool classes. A plurality of memory pools each having a 
predetermined fixed size are constructed, with each of the 
plurality of fixed pool classes being associated with one of 
the plurality of memory pools. New objects belonging to a 
selected one of the fixed pool classes are instantiated, with 
the instantiation step including the step of allocating 
memory for the new object from the associated memory 
pool. A system for managing memory in an object oriented 
program operating on a computer system is also provided 
that includes a memory pool class and a plurality of sub- 
classes of that memory pool class, where the object oriented 
program is capable of using and instantiating objects belong- 
ing to the subclasses. The system also includes a plurality of 
memory pools each having a predetermined fixed size, 
where each of the plurality of subclasses is associated with 
one of the plurality of memory pools, and wherein memory 
for objects of a selected subclass that are instantiated by the 
object oriented program is allocated from the associated 
memory pool. 

20 Claims, 2 Drawing Sheets 
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OBJECT ORIFNTKD PROGRAM MEMORY 
MANAGEMENT SYSTEM AND METHOD 
USING FIXED SI /ED MEMORY POOLS 

TECHNICAL FIELD OF THE INVENTION 

The present invcnlion relates in general to the field of 
computer programming. More particularly, the invention 
relates to a system and method for managing memory in 
object oriented programs in which objects arc allocated and 
deallocated from fixed size memory pools rather than from 
the heap. 

BACKGROUND OF THE INVENTION 

Object oriented programming is a powerful programming 
tool. An object oriented program is one that has as its basic 
foundation a set of building blocks called objects, each of 
which is a representation or abstraction of a physical cle- 
ment or a logical concept. An object is defined by a set of 
data that represents specific attributes or properties of the 
object, and a set of functions or methods that can be 
performed on or by the object. Each object can receive 
messages instructing it to perform a particular function, or 
send such messages to other objects. Objects are reusable, 
and can also be called on by a variety of different application 
programs. 

Objects must reside in memory, and each time an object 
is created by an application program memory must be 
allocated to store that object. In known objected oriented 
programs, memory is allocated form a common pool of free 
memory that is available to all application programs, com- 
monly known as the heap. Although the act of allocating 
memory itself is a relatively simple task if memory is 
available, continued allocation of memory for new objects 
without also deallocating memory for objects that are no 
longer being used will slowly deplete the available memory 
space. This slow depletion of memory is referred to as a 
"memory leak", and is a common problem in current object 
oriented programs. Further, known object oriented programs 
also continue to create new objects while the application 
program is running without keeping track of the availability 
of memory space in the heap. Consequently, any memory 
leaks may reach a critical point at any time. The obvious 
consequences of this are program or system failure, and loss 
of data. Thus, memory allocation and deallocation in object 
oriented programming, otherwise known as memory 
management, is of great concern and has traditionally been 
extremely problematic. 

Memory management concerns have previously been 
addressed by various types of products or programs that 
manage the deletion of objects, such as well known garbage 
collection products. Although somewhat effective in reduc- 
ing the danger of memory leaks, allocation of objects from 
the heap still proceeds during program execution without 
any feedback regarding available memory. Thus, it is always 
possible that insufficient memory will result in program or 
system failure. Accordingly, programs that manage the dele- 
tion of objects do not address a fundamental problem; that 
in known object oriented programs memory allocation 
occurs continuously and in ignorance of the state of avail- 
able memory. 'Ilius, it can never be guaranteed that sufficient 
memory will be available for the duration of the running 
lime of the application program. 

SUMMARY OF THE INVENTION 

Accordingly, a need current l> exists for a system and 
method of managing memory in object oriented programs 
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that will ensure that adequate memory will be available at all 
times throughout program operation so as to avoid program 
.failure and eliminate the problems associated with memory 
leaks. 

In accordance with the present invcnlion, a method is 
provided for managing memory in an object oriented pro- 
gram that is capable of using a plurality of fixed pool classes 
and a plurality of objects of those classes. The method 
includes the steps of constructing a plurality of memory 
pools each of a predetermined fixed size, where each of the 
fixed pool classes is associated with one of the plurality of 
memory pools; and instantiating a new object belonging to 
a selected one of the fixed pool classes, the instantiating step 
including the step of allocating memory for the new object 
from the associated memory pool. Further, when an object 
of a fixed pool class is deleted, memory is deallocated to the 
associated memory pool. 

Further, in accordance with the present invention a system 
for managing memory in an object oriented program oper- 
ating on a computer system is also provided comprising a 
memory pool class, and a plurality of fixed pool subclasses 
of the memory pool class, where the object oriented program 
is capable of using and instantiating objects belonging to the 
subclasses. The system further includes a plurality of 
memory pools each of a predetermined fixed size, where 
each of the plurality of fixed pool subclasses has one of the 
plurality of memory pools associated therewith, and where 
the memory for the objects of a selected subclass that are 
instantiated by the object oriented program is allocated from 
the associated memory pool. Likewise, when objects of the 
subclasses are deleted, memory is deallocated to the asso- 
ciated memory pools. 

BRIEF DESCRIPTION OF THE DRAWINGS 

For a more complete understanding of the present inven- 
tion and the advantages thereof, reference is now made to 
the following description taken in conjunction with the 
accompanying drawings in which like reference numbers 
indicate like features wherein: 

FIG. la is a simplified diagram illustrating attributes and 
methods of a class; 

FIG. lb is a simplified diagram illustrating objects of the 
class shown in FIG. la; 

FIG. 2 is a simplified block diagram illustrating the 
overall architecture of an exemplary system according to the 
present invention; 

FIG. 3 is a simplified Mow chart illustrating the process of 
constructing fixed size memory pools; 

FIG. 4 is a simplified flow chart illustrating the process of 
allocating an object from a fixed size memory pool; 

FIG. 5 is a simplified illustration of a fixed si/e memory 
pool that contains object "shells", and a separate database 
for storing object data; and 

FIG. 6 is a simplified How chart illustrating the process of 
deallocating an object from a fixed size memory pool. 

DETAILED DESCRIPTION 

At the root of object-oriented programming are the con- 
cepts of classes and objects (or instances) of these classes, 
A class is a generic description of the attributes or charac- 
teristics and of behaviors or methods that all objects within 
that class may possess. For example, as shown in FIG. \a, 
members of the class "Student" 1 may each have as 
attributes 2 a name, age, and social security number. The 
methods 3 that can be performed on members of the class 
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"Student" include either to add (addfile) or delete (delelelile) caled from memory pool Pool A 206; and all objects bclong- 
the student represented by the defined attributes from a file, ing to ClassB 205, such as "Obj. B," and "Obj. B 2 " 209, are 
such as a file listing the students enrolled in a particular allocated and deallocated from memory pool PoolB 207. 
college course. Faeh object or instance of the class will Although only two subclasses of Memory Pool 203, and a 
contain specific data values corresponding to each generic 5 separate object pool corresponding to each of these sub- 
attribute of the class. For example, as shown in FIG. 1/?, for classes is shown in PIG. 2, one skilled in the art will 
Object X 4 the value of 30 corresponds to the age attribute, understand that various other embodiments could also be 
and the value 1 23-45-6789 corresponds to the social security implemented. Por example, additional layers of subclasses 
number (SStf) attribute. Likewise, for Object Y 5 the value could be included, as could additional numbers of subclasses 
of 40 corresponds to the age attribute and the value 234- 10 at each layer. Purther, multiple classes may also allocate and 
56-7890 corresponds to the social security number attribute. deallocate objects from the same object pool. 
Thus, the values taken on by the object for the various As indicated, all classes encapsulated by McmoryPool 
attributes define the state of the object. The methods defined 203 will allocate and deallocate objects from a designated 
in the class, however, remain the same for all objects in that fixed size memory pool rather than from the heap. According 
class, and in the absence of overloading, will also remain the 15 to the present invention, the fixed size memory pools 206, 
same for all subclasses of that class due to the well known 207 are constructed during program initialization, and 
principle of inheritance. Finally, objects arc called upon by because all objects are allocated and deallocated from the 
application programs to perform certain functions by send- pool(s), the size of each memory pool is critical and must be 
ing messages to the appropriate object. In some instances, determined prior to program run time. ITie size of the pool 
these messages require an object to call upon other objects 20 must be sufficient to store the maximum number of objects 
by sending messages to those other objects. that could be concurrently allocated during program opera- 
As previously indicated, known object oriented programs lion in order to avoid memory deficiencies. ITius, both the 
create new objects to carry out necessary functions, and maximum number of concurrently allocable objects and the 
allocate memory for those objects from the heap as program size of the objects must be accurately determined before the 
execution proceeds. The present invention avoids the dis- 25 memory pool can be created. This number can be deter- 
advanlages of these known object oriented programs by mined by calculation, experimental evidence, extrapolation, 
providing a system and method for managing memory that testing or the like. Once ascertained, information regarding 
allocates and deallocates objects from fixed size memory the size of each object and the maximum size of the memory 
pools rather than from the heap. The size of the memory pool pool (the "memory pool data") is stored in one or more files, 
is such that it is sufficient to store the maximum number of 30 such as initialization files 202, that can be accessed by the 
objects that could be concurrently allocated by the applica- application program that will call on these objects, 
tion program, and the proper size is set during program Assuming the necessary data has been stored in the 
initialization. By integrating memory allocation and pro- initialization file 202, memory pool initialization will then 
gram initialization, the system and method of the present proceed as shown in FIG. 3. On program startup, the 
invention ensures that there will be sufficient memory for 35 application program 200 will first initialize those classes that 
object allocation at all times. Further, because objects are are to be called on during program execution (step 300). As 
only allocated and deallocated from a fixed size memory is well known in the art, each class includes a class specific 
pool, there is never a danger that memory leaks or like method "main" (220 in PIG. 2) that is called on to initialize 
problems will lead to program failure. As will be described the class. For classes whose objects arc allocated and 
below, 1 ho inventive system and method applies the prin- 4(1 deallocated from fixed size memory pools, "main" will 
ciplcs of overloading and inheritance to ensure that all direct the application program to go to the appropriate 
objects are allocated and deallocated from the appropriate initialization file 202, parse through that file, and extract 
fixed size memory pool rather than from the heap, and from that file the memory pool data corresponding to that 
therefore, is completely transparent to application programs class (step 301). Once the information is obtained, the 
that call on these objects. 45 application program 200 will, in step 302, construct a 
Hie architecture of the system will now be described with memory pool of the appropriate size by allocating from 
reference to FIG. 2. There are multiple application programs available memory the amount of memory for that pool that 
200 that are each capable of calling on objects that will be is specified by the memory pool data 211 in the initialization 
allocated and deallocated from fixed size memory pools. file 202. 

These application programs 200 operate in a standard object 50 In one embodiment, the application program will allocate 

oriented program environment. In one embodiment, the the memory space, and also perform the additional step of 

application programs use the C++ programming language, creating the proper number of "shell" objects within that 

and thus arc linked to a C++ compiler 201. Application allocated space (step 303). A "shell" object is an object that 

programs 200 are also linked to one or more initialization has been created and is stored within the allocated memory 

files 202 that contain files and data necessary for program 55 space, but has not yet been assigned data values for the 

initialization. various named attributes to define the state of that object. 

Application programs 200 encapsulate a class "Memory- The creation of "shell" objects is advantageous when the 

Pool" 203, which itself encapsulates the fixed size memory number of objects called on at any one time by an applica- 

pool scheme. Representative classes. Class A 204 and ClassB lion program is far less than the number of physical possi- 

205, are subclasses of McmoryPool 203, and thus inherit the 00 bilities. Under such circumstances the data for each object 

attributes and methods of the McmoryPool class. ClassA may be stored elsewhere, such as in a separate database (502 

204 and ClassB 205 are each linked to a fixed size memory in TIG. 5). When needed, an object "shell" will be taken 

pool, PuolA206 and PoolB 207 respectively, from which all from the memory pool and filled with the appropriate data 

objects within the class are allocated and deallocated, and from the database, as will be described in further detail 

are Ihcicfore, referred to as fixed pool classes. For example, <»5 below. 

it can be seen that all objects that belong to ClassA 204, such Accordingly, all fixed size memory pools are constructed 

as "Obj. A," and "Obj. A/' 20K, are allocated and deallo- during initialization. For those classes that allocate and 
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deallocate objects from their own memory pools, class 
initialization will include construction of such a pool. For 
those that share a memory pool, as in an alternative embodi- 
ment of the present invention, the method "main" in these 
classes will adjust for this by simply not directing the 5 
application program to construct a new and separate 
memory pool. 

Now that all necessary fixed size memory pools have been 
constructed, the manner by which objects are allocated and 
deallocated from the appropriate pools rather than from the ]Q 
heap will now be described with reference to FIGS. 2 and 4. 
As is well known, the C++ operators that manage memory 
allocation are "new" and ''delete" (213 and 214 in FIG. 2). 
"New", followed by the appropriate pointer to a designated 
class, causes memory to be allocated from the heap to create 
a new object of that class, and "delete" causes a specified 15 
object to be deleted from memory, thereby deallocating 
memory to the heap. It is also well known, however, that any 
C++ operators, including "new" and "delete", can be over- 
loaded by a subclass that uses the same operator name, but 
redefines the method. For example, as shown in FIG. 2, each 20 
of subclasses ClassA 204 and ClassB 205 include methods 
"new" 215 and "delete" 216. The methods within subclasses 
ClassA and ClassB will be referred to hereinafter as NEW 
and DELETE only to avoid confusion, but it is to be 
understood that these methods arc called by the same name 25 
as the C++ operators "new" and "delete" so as to overload 
the C++ operators. Although called on by the same name, 
NEW and DELETE have been redefined to contain addi- 
tional parameters that instruct that memory allocation for the 
desired object (or deallocation for an object to be deleted) is 30 
to be from a specified fixed size memory pool rather than 
from the heap. Thus, NEW and DELETE overload the C++ 
operators "new" and "delete", and cause all objects for that 
class to be allocated and deallocated from the named object 
pool. 35 

Referring now to FIG. 4, the application program will first 
send the C++ message "new" to a particular class, i.e. 
ClassA (step 400). Because ClassA includes its own NEW 
method, receipt of the C++ "new" message from the appli- 
cation program will be overload by NEW. In one 40 
embodiment, NEW calls on another method "allocate" 402 
(see also 225 in FIG. 2), which is the method that actually 
causes the object to be allocated from the designated pool, 
and which is defined by McmoryPool 203 and inherited by 
ClassA. To perform the actual allocation, "allocate" will go 45 
to the memory pool named in the parameters of NEW, and 
proceed to iterate through the memory space in that memory 
pool until it locates a sufficient amount of unallocated 
memory 403. It will then allocate that located space for the 
new object 404. 50 

As was stated above, in one embodiment object "shells" 
may be created within the fixed size memory pool during 
program initialization. FIG. 5 illustrates multiple object 
"shells" 501 within object pool FoolX 500. Under such 
circumstances, the data for all objects is stored elsewhere, 55 
such as in a separate database 502. When an object is 
allocated from the pool, it is removed from the pool and the 
data necessary to define the state of the object is extracted 
from database 502 and assigned to the object. Hiis defined 
object 503 can then be used by the application program. If 60 
during the use of the object changes arc made to the object's 
data, the database will be updated with the new information. 
The object will be "active" while needed to perform a 
particular function, and returned to the pool thereafter for 
use again at a later time. o.s 

The C++ operator "delete" is also overloaded by 
DELETE in a manner analogous to that by which the C+ + 
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operator "new" is overloaded. Referring to FIG. 6, when the 
useful life of an object has expired, the application program 
will send the C++ "delete" message to a particular object of 
a particular class (step 600). As any class that encapsulates 
the fixed size memory pool scheme includes its own method 
DELETE (215 in FIG. 2), the C++ operator "delete" is 
overloaded by DELETE at the subclass level, i.e. ClassA 
204, in step 601. DELETE differs from "delete" in that it 
contains additional parameters that name the specific 
memory pool from which the object is to be deleted. In one 
embodiment, DELETE further calls on a method "deallo- 
cate" (226 in FIG. 2) defined by Memory Pool 203 and 
inherited by ClassA (602), that will direct the deletion of the 
object from the named memory pool in which it resides in 
step 603. If the memory pool is of the type that includes 
object "shells", the data will be deleted from the object, and 
the empty object "shell" returned to the memory pool. 

From the above description it is clear that the present 
invention provides a new and superior system and method 
for managing memory in object oriented programs. By 
allocating and deallocating objects from fixed size memory 
pools rather than from the heap, and by constructing these 
fixed size memory pools during initialization, the inventive 
system and method ensures that memory sufficient to sup- 
port a particular object oriented program will be available 
throughout the run time of the application program. 

Other modifications of the invention described above will 
be obvious to those skilled in the art, and it is intended that 
the scope of the invention be limited only as set forth in the 
appended claims. 
What is claimed is: 

1. A method for managing memory in an object oriented 
program, said object oriented program being capable of 
using a plurality of fixed pool classes and a plurality of 
objects belonging to said fixed pool classes, comprising the 
steps of: 

determining a maximum number of objects that may be 
allocated by the object oriented program for each fixed 
pool class; 

determining a size of each object that may be allocated; 
constructing a plurality of memory pools upon initializa- 
tion of the object oriented program, each of said 
plurality of memory pools having a predetermined 
fixed size, each of said plurality of fixed pool classes 
being associated with one of said plurality of memory 
pools, wherein a size of each memory pool is deter- 
mined from the maximum number of and size of 
objects that may be concurrently allocated for each 
associated fixed pool class during operation of the 
object oriented program; and 
instantiating a new object belonging to a selected one of 
said fixed pool classes, said instantiating step including 
the step of allocating memory for said new object from 
said associated memory pool. 

2. A method according to claim 1, wherein said instanti- 
ating step further comprises: 

invoking a first object creation method intended to allo- 
cate memory for said new object from memory other 
than that of said associated memory pool, said first 
object creation method being inherited by said selected 
fixed pool class; 
overloading said first object creation method with a 
second object creation method defined by said selected 
fixed pool class, said second object creation method 
causing memory for said new object to be allocated 
from said associated memory pool. 
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3. A method according to claim 2, further comprising the 
step of: 

deleting an existing object belonging to one of said fixed 
pool classes, said deletion causing the deallocation of 
memory from said existing object to the memory pool 
associated with the fixed pool class to which said 
existing object belongs. 

4. A method according to claim 3, wherein said deleting 
step further comprises: 

invoking a first object deletion method intended to deal- 
locate memory from said existing object to memory 
other than that of said associated memory pool, said 
first object deletion method being inherited by the fixed 
pool class to which said existing object belongs; and 

overloading said first object deletion method with a 
second object deletion method defined by said fixed 
pool class to which said existing object belongs, said 
second object deletion method causing memory to be 
deallocated from said existing object to said associated 
memory pool. 

5. A method according to claim 1, wherein said construct- 
ing step further comprises: 

extracting from an initialization file memory pool data 
corresponding to each of said memory pools to be 
constructed, said memory pool data including a size of 
said memory pool to be constructed, and a size of 
objects to be allocated and deallocated from said 
memory pool; 

allocating sufficient memory to construct said plurality of 
memory pools according to said corresponding 
memory pool data, 

6. A method according to claim 5, wherein prior to said 
instantiation step said plurality of fixed pool classes are 
initialized, and said constructing step occurs during said 
initialization. 

7. A method according to claim I, wherein said construct- 
ing step comprises associating each of said plurality of fixed 
pool classes with a different one of said plurality of memory 
pools. 

8. A method according to claim 1, wherein said construct- 
ing step comprises associating at least two of said plurality 
of fixed pool classes with a selected one of said plurality of 
memory pools. 

9. A system for managing memory in an object oriented 
program operating on a computer, comprising: 

a memory pool class; 

a plurality of fixed pool subclasses of said memory pool 
class, said object oriented program being capable of 
using and instantiating objects belonging to said plu- 
rality of fixed pool subclasses", 

a plurality of memory pools each of a predetermined fixed 
size constructed during initialization of the object ori- 
ented program, each of said plurality of fixed pool 
subclasses having one of said plurality of memory 
pools associated therewith, wherein a size of each 
memory pool is determined from the maximum number 
of and size of objects that may be concurrently allo- 
cated for each associated fixed pool subclass during 
operation of the object oriented program; 

wherein memory for said objects of each of said fixed 
pool subclasses instantiated by said object oriented 
program are allocated from said associated memory 
poof 

10. A system according to claims 9, wherein each of said 
plurality fixed pool of subclasses defines an object creation 
method that causes memory for said objects instantiated by 



said object oriented program to be allocated from said 
associated memory pool. 

11. A system according to claim 10, wherein said defined 
object creation method overloads an inherited object cre- 

5 alion method intended to cause said memory to be allocated 
from memory other than that of said associated memory 
pool. 

12. A system according to claim 11, further comprising an 
initialization file for storing memory pool data for each of 

10 said memory pools, said memory pool data including the 
predetermined size of each of said memory pools, and the 
size of objects to be allocated from each of said memory 
pools. 

13. A method for managing memory in an object oriented 
is program, said object oriented program being capable of 

using a plurality of fixed pool classes and a plurality of 
objects belonging to said fixed pool classes, comprising the 
steps of: 

constructing a plurality of memory pools, each of said 
20 memory pools having a predetermined fixed size, and 
each of said plurality of fixed pool classes being 
associated with one of said plurality of memory pools, 
wherein a size of each memory pool is determined from 
the maximum number of and size of objects that may 
25 be allocated for each associated fixed pool class; 

constructing a plurality of object shells within a memory 
pool associated with a selected fixed pool class, each of 
said object shells being capable of becoming a defined 
object of said selected fixed pool class by receiving 
30 attribute data, said attribute data being stored in a 
database, wherein each object shell has not been 
assigned data values to define a stale of an object; and 
instantiating a new object belonging to said selected fixed 
pool class by retrieving said attribute data from said 
database and inserting said attribute data into one of 
said object shells of said associated memory pool. 

14. A method according to claim 13, wherein said instan- 
tiating step further comprises: 

invoking a first object creation method intended to allo- 
cate memory for said new object from memory other 
than that of said associated memory pool, said first 
object creation method being inherited by said selected 
fixed pool class; and 
overloading said first object creation method with a 
second object creation method defined by said selected 
fixed pool class, said second object creation method 
causing memory for said new object to be that of an 
object shell within said associated memory pool. 

15. A method according to claim 14, further comprising 
the steps of: 

deleting attribute data from an existing object of a fixed 
pool class associated with a memory pool that includes 
object shells; and 
returning said object shell to said associated memory 
pool. 

16. A method according to claim 13, wherein said deleting 
step further comprises: 

invoking a first object deletion method intended to dcal- 
60 locate memory from said existing object to memory 
other than that of said associated fixed memory pool, 
said first object deletion method being inherited by the 
fixed pool class to which said existing object belongs; 
overloading said first object deletion method with a 
u5 second object deletion method defined by Ihe fixed [Hiol 
class to which said existing object belongs, said second 
object deletion method causing said attribute data to be 
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deleted and said object to be returned to said associated 
memory pool. 

17. A method according to claim 13, wherein said con- 
structing step further comprises: 

extracting from an initial i/alion file memory pool data 5 
corresponding to each of said memory pools to be 
constructed, said memory pool data including a size of 
said memory pool to be constructed, and a size of 
objects to be allocated and deallocated from said 
memory pool; 10 

allocating sufficient memory to construct said plurality of 
memory pools according to said corresponding 
memory pool data. 
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18. A method according to claim 17, wherein prior to said 
constructing step said plurality of fixed pool classes are 
initialized, and said constructing step occurs during said 
initialization. 

19. A method according to claim 13, wherein said con- 
structing step comprises associating each of said plurality of 
fixed pool classes with a different one of said plurality of 
memory pools. 

20. A method according to claim 13, wherein said con- 
structing step comprises associating at least two of said 
plurality of fixed pool classes with a selected one of said 
plurality of memory pools. 

* * * * * 
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